home *** CD-ROM | disk | FTP | other *** search
/ MacTech 1 to 12 / MacTech-vol-1-12.toast / Source / MacTech® Magazine / Volume 03 - 1987 / 03.07 Jul 87 / bit map source / notes / larry on bitmaps < prev    next >
Encoding:
Text File  |  1987-04-18  |  2.0 KB  |  44 lines  |  [TEXT/MPS ]
  1. In article <8704030710.AA19696@ucbvax.Berkeley.EDU> you write:
  2. >
  3. >INFO-MAC Digest           Friday, 3 Apr 1987       Volume 5 : Issue 74
  4. >
  5. >
  6. >Date: Wed, 1 Apr 87 23:26:40 PST
  7. >From: digiorgi@Jpl-VLSI.ARPA
  8. >Subject: Re: FullPaint
  9. >
  10. >in issue #73, a complaint was made concerning FullPaint and the fact that it
  11. >does not recognize the FPD and 'stepping out' large displays.  The reason it
  12. >doesn't is due to a (probable) three line piece of code: they didn't check
  13. >for screenBits.bounds at the top of the program to get the real size of the
  14. >screen from the system global, they hardwired the screen size into the
  15. >code.
  16.      
  17. This is probably NOT the reason why FullPaint doesn't take advantage of the
  18. large screen.  I talked to some of the Ann Arbor programmers about a year
  19. ago (at the MacHack Developers Conference), and they know the Mac too well
  20. to have made such a mistake.  (Also, I wrote a demonstration painting
  21. program using MacApp, so I know a little about the internals of such
  22. programs.)
  23.      
  24. The problem has to do with the internal memory needed by bitmap painting
  25. programs.  At the very least, you need 2 offscreen bitmaps (one for UNDO and
  26. the other for general use).  Certain complicated commands might require
  27. other buffers; plus, to get adequate speed you might want to cache other
  28. bitmaps.  (My recollection is that FullPaint uses 5 or so internal buffers.)
  29.      
  30. Each of the offscreen bitmaps must be (in general) as large as the maximum
  31. area the user can change at one time.  A full page MacPaint/FullPaint/...
  32. document requires 55K, while a Mac screen size bitmap requires 22K.
  33.      
  34. Therefore you have to tradeoff between: (1) number of documents open at
  35. once, (2) minimum memory required to run the program, and (3) maximum area
  36. the user can edit at once.  Ann Arbor's decision was to provide a program
  37. that could open 4 documents at once on a 512K machine.
  38.      
  39. This is not to excuse Ann Arbor from providing support to users; I just
  40. wanted to point out that there are some technical issues that people might
  41. not realize.
  42.      
  43. Larry
  44.